Numerous attempts have been made to construct software applications out of “components,” or reusable pieces of software. These desired construction techniques are analogous to an often used manner of building hardware systems out of prepackaged pieces, more specifically chips, by creating custom interconnections. By using a construction approach utilizing components, it is believed that the software construction cost will be reduced or, alternatively, that the software construction productivity will increase, when compared to techniques that start anew for each new software application.
Software components declare a set of inputs and outputs, which are used to communicate with other components in the system. Such inputs and outputs may be considered analogous to pins on a chip in hardware system construction. Ideally the components are completely encapsulated, in that they only communicate via the declared input and output ports. The encapsulation of components provides numerous benefits. For example, encapsulated components may be replaced by other implementations, as long as the inputs, outputs, and semantics are identical. Additionally, applications built from encapsulated components are easier to analyze, optimize, and transform, because there is no need for the system to analyze internal implementations of the components.
An example of an encapsulated component system is the NIL programming language. See, for example, “A New Programming Methodology for Long-Lived Software Systems,” IBM J. Res. Develop., Vol. 28, No. 1, January 1984.
Another useful approach to reducing software complexity and improving software productivity is declarative programming. Declarative programming attempts to describe the desired behavior or goals of the system, the “what,” but leaves the specific implementation of the system, the “how,” undefined. In declarative programming it is reasoned that only the behavior is important, and a description of the implementation is an unnecessary loss of productivity. Examples of declarative programming languages include Haskell and Prolog. In contrast, most applications today are implemented in imperative programming languages, such as Java and C++. Imperative languages are used to describe the application using a step-by-step approach, for example, first, read input field 1; second, display a message in text-box 2.
Imperative languages typically have the concept of a “program counter” which indicates exactly where the flow of execution is at all times, and the ability to set “breakpoints”, which suspend the program when the flow of execution reaches a certain location in the program, utilized, for example, for debugging. In contrast, declarative programs do not have a concept analogous to a program counter. Note that declarative systems may be implemented using imperative languages.
Virtually all applications require access to data, which is typically stored in a database. A relational model, which provides access to data using relational algebra has been the most successful approach yet devised for storing and accessing data (see “A Relational Model of Data for Large Shared Data Banks”, Communications of the ACM, Vol 13 No. 6, June 1970). In its pure form, the relational model and algebra provide a declarative approach to accessing data. More specifically, they describe what data is desired, but not how to retrieve it. While componentization, the relational model, relational algebra, and declarative programming techniques and their respective benefits are well known, they have not been applied together in an existing system.
As a counter-example, the Microsoft Windows Presentation Foundation (formerly named “Avalon”) explicitly mixes declarative descriptions of visual layouts with imperative (non-declarative) procedural code (see “Code Name Avalon: Create Real Apps Using New Code and Markup Model”, MSDN Magazine, January 2004). Microsoft states that [imperative] programming languages are “clunky for the job of laying out text, images, and controls”, and declarative (“markup”) approaches are “hopelessly inept when it comes time to interact with the user”. Thus both approaches must be used together in Avalon. The declarative part of the application (“XAML”) must be supplemented by “real [imperative] programming code”, which is embedded directly in XAML or placed in a separate file.